In general, the present invention relates to authoring of text and computer-executable code, and more particularly to techniques for automatically generating HTML (hypertext markup language) script.
In recent years, the Internet has experienced tremendous growth. Its rapid development has resulted in a growing number of new uses of the Internet and its multimedia component, the World Wide Web (the Web). In particular, demand for richer, faster and more interactive web sites have been driven increasingly sophisticated users. To attract more demanding users, commercial and corporate Internet site authors attempt to stay ahead of their competition by providing more sites for users and potential customers.
Enabling the growth of the Internet, corporate users have expanded the application of HTML into intranets. In this area, creators of authoring tools have strived to enable authors to create content-rich web sites with minimal effort.
When the world-wide web was first invented, the language used to publish data was a simple text-oriented formatting device. A server would send HTML documents to a client computer running a browser that would display the HTML content on the screen according to the formatting information embedded in it. The browser would transmit a request for a particular HTML file and this HTML the server in response to the request would transmit file to the client. These HTML documents contained references to graphic files, which were also sent from the server to the client and displayed according to the embedded instructions in the HTML code.
As the web grew in popularity, second-generation web-sites added more sophisticated formatting such as tables and frames and displayed graphics as background along with other formatting devices. Still, content was still contained in files that were simply transmitted to browsers in response to requests for particular documents. In addition, server-side programs would custom-generate HTML documents in response to requests for specific information. For example the server would access a database in response to a search query and produce an ephemeral HTML document that it would then send to the browser. However, such interactive sites were not common because of the sophisticated server-side scripting that was required. Even after third generations sites, which provided Java script applets, Adobe PDF files, animated graphic files, offered rather sophisticated look to sites, most sites relied on simply pushing fixed documents and applets to browsers in response to specific requests.
Recently with the introduction of Microsoft(copyright) Corporation""s (of Redmond, Wash.) Visual InterDev(copyright) 1.0 product, the process of creating sites that custom-generate files for consumption and display by browsers has been dramatically simplified by employing various interesting techniques. These include:
1. Server-side scripting (Active Server Pagesxe2x80x94ASPxe2x80x94developed by Microsoft(copyright)) that allows dynamic web applications similar to Java, DHTML, and Active-X, which run on the client. An event occurring on the client is transmitted to the server application and new page-layout data is sent to the client to show the result.
2. ASP objects that are wizard-like components that work similarly to Active-X controls implemented on clients. They have properties, methods, and events and must be instantiated (except for some pre-instantiated components that are always available).
3. Web Bots included in Front Page 97(copyright) are server-side components that add functionality like that provided by CGI scripting.
4. Visual InterDev(copyright) 1.0""s raison d""etre, perhaps, is the convenient integration of databases with web sites without sophisticated programming. This integration is simplified through the use of a compatibility standard and a suite of pre-defined tools that may be incorporated in ASP script.
ASPs may be called using a URL (uniform resource locator) which may refer to the ASP file xe2x80x9cpage.aspxe2x80x9d as follows: xe2x80x9c less than http://www.anycompany.com/page.asp greater than .xe2x80x9d While the following description uses the term xe2x80x9cactive server pagexe2x80x9d or xe2x80x9cASP,xe2x80x9d any document or page which contains a script which, when executed, pulls data from a database and forwards it to an end application (another document or page) falls within the scope of the term, ASP, as used herein.
Requests to ASPs commonly take the form of user requests from a client""s browser. An example of a request is a request for current sport scores from a web site. In the process of requesting, the browser, located on the client, accesses the ASP with a request that provides additional information to the server. For example, an active server page, named xe2x80x9cscoresxe2x80x9d, may be connected to a database storing all current sport scores. To access any particular set of scores, a browser user specifies to the server which scores are of interest (here, baseball scores). Next, the browser attempts to access the  less than scores.asp greater than  file with a xe2x80x9cbaseballxe2x80x9d parameter attached to the file request (e.g.,  less than scores.asp?sport=baseball greater than . In this example, xe2x80x9cscores.aspxe2x80x9d is the active server page on the server, xe2x80x9csportxe2x80x9d is a filter control handling the parameter xe2x80x9cbaseballxe2x80x9d. In response to this request, the server forwards the desired baseball scores in HTML format back to the browser. Upon receiving this new information, the current page is flushed and the new HTML data (containing the baseball scores in a predefined format) is displayed in the end user""s browser. The returned information can also be images, documents, links to images or documents, or other data.
There are a few downsides to the use ASPs in complex sites. First, referring to an ASP with the current scripting parameters is laborious especially with long parameter strings. Developers who are familiar with higher order languages (including C++ and VISUAL BASIC 5.0(copyright)) must revert to complex naming schemes for creating the client and server side scripts. This reversion creates the opportunity for errors and the need for additional debugging time.
Also, as currently used, each ASP is directed to a single script. For a large web site, with each and every ASP, no matter how closely they are related, the ASPs require a separate files. Thus, the number of required files for a complex site grows significantly. To this end, maintenance of the site becomes extremely complex and inefficient as each modification to the site may require significant redrafting code for the multiple ASPs. The near duplication of the ASPs can require significant expenditures in time and planning of the web site, when a number of ASPs are so closely related. Currently, there is no efficient way of consolidating ASPs into related groups.
In addition to the above functional elements, Visual InterDev(copyright) 1.0 includes a host of features that relate to the development environment. Basically these features include such well-known user-interface features such as drag-and-drop, WYSIWYG, etc. Developers are allowed to instantiate programming objects using a visual metaphor. These ideas are well developed in the Microsoft Visual Basic(copyright) product which takes these ideas substantially further than was possible in Visual InterDev(copyright) 1.0 for a number of reasons which are explained below.
The development of web applications is complicated by a number of features stemming from the web context. In a classical client-server context, the capabilities of the client computer and those of the server computer are defined in advance of development of applications. In the web environment, the capabilities of the client are not clearly defined. Some clients run browsers such as 2.xc3x97 browsers lack capabilities, such as the ability to run Java applets that are present in 3.xc3x97 and 4.xc3x97 browsers. A web application that seeks to provide sophisticated functionality is confronted with the problem of where to run the code that generates the sophisticated functionality sought: on the client or on the server. Some simple tasks can be performed on xe2x80x9cdumbxe2x80x9d clients such as forms. A programmer is basically stuck with the problem of writing programs that can handle both situations: putting the sophistication on the server, sending plain HTML to the dumb clients as well as putting the sophistication on the client sending program components to a smart client and letting the client run them.
Another feature of web applications is that the client-server interaction is both ephemeral and contentious in that the number of different clients potentially compete for the limited resources. For this reason, web pages that are generated by server scripts are generally dumped after they are sent to the client. The request data transmitted by the client can be saved for a limited xe2x80x9clifetimexe2x80x9d to allow a user to recall the web page. (xe2x80x9cLifetimexe2x80x9d may embrace any criterion used for determining whether to persist a page, for example, for a period of time after the user""s last visit or as long as the user continues to view and revisit the page without visiting another site, etc.) This involves regeneration of the page. This situation is not too bad in and of itself. However, scripting the calling and called pages to handle the control flow required inevitably involves a lot of tedious old-fashioned sequential coding. That is, at a minimum, to add a page""s content, or to employ any script incorporated in the page, to a calling page, the calling page must be scripted to handle the called page, and the called page, a return to the calling page. Conditional branching would also be involved which can be tedious and complex.
There is currently no way to incorporate the functionality of a destination ASP into a current page. Placing the following tag on a client""s page xe2x80x9c less than A HREF=xe2x80x9chttp://www.anycompany.com/alpha/page.aspxe2x80x9d greater than xe2x80x9d allows the user to select the tag and navigate to the ASP named xe2x80x9cpage.aspxe2x80x9d in the xe2x80x9calphaxe2x80x9d directory of the www.anycompany.com site. However, once the page.asp is selected with specific parameters, the current page is lost with all its information. The only way to return to the current page and modify the information transmitted to the ASP is by backtracking and re-entering the previously entered parameters. While object-oriented programming exists with respect to other programming areas, there is little or no support for objects in program files of HTML pages including ASPs.
Returning to the general problem of xe2x80x9cmanaging state,xe2x80x9d consider the xe2x80x9clifetimexe2x80x9d of a simple ASP page that contains a form for data-entry into a database:
User navigates to the pagexe2x80x94an HTTP GET causes the server to run the ASP to produce a page for the client.
The browser displays the page and the user enters data and submits the form, causing an HTTP POST to the server.
The server runs the ASP page again to process the post. The code parses the post parameters, updates the database and produces a new version of the page for the client that informs the user the data has been successfully entered.
It is clear that if the web developer wants to maintain some state information over the lifetime of the page, then simply declaring a variable in client or server code is not sufficient. And obviously the developer must do much more if it is necessary to share this state information between code on the client and server.
There are three categories of state information:
Pagexe2x80x94maintained for the lifetime of a page
Sessionxe2x80x94maintained for the duration of a user""s session
Applicationxe2x80x94maintained for the duration of the application for all users
ASP supports caching data and objects in the server in the Session and Application objects, providing a means for maintaining session and application state information. A common technique for managing page state is to place values in hidden form elements. The form elements travel with the page to the client, can be modified, and they travel with the HTTP POST data back to the server. A developer using this technique must write server code to create the form elements on the page, write client code to access the form elements through the Document Object Model, write more server code to parse the values from the post parameters, and must be sure to write the values back out in the form elements for the new page that is sent to the client in response to the post. This is another common task that complicates web programming and results in duplication of effort. In addition to the coding overhead, the sheer complexity of sites with a high degree of sophisticated functionality can be oppressive. Being stuck with old-fashioned sequential programs makes the management of the development and improvement of web sites exceedingly complex, even unwieldy.
Finally, the way a client or server accesses an ASP is through script on the client/server page. Managing these scripts can be confusing as the scripts on the server and the client may look similar, yet require slightly different structures and parameter fields. Adding to the level of complexity, in some instances, the server script may generate the client script. To keep track of the complexity of scripts, some page editors color code client script differently from server script. However, as pages become increasingly complex, color-coding is not sufficient to support complex site management as the site becomes increasingly harder to conceptualize.
A method and apparatus for the development of web sites treats web page script files and components according to an event-driven model and more generally as objects with exposed methods and properties in a manner that, at development time, provides a common appearance whether the associated script or components are ultimately run on the client or the server. According to a feature, script files and even simple HTML pages are referenced as objects to provide a simple programming naming structure (also referred to as a simplified namespace) and obviate sequential coding structure otherwise required to cross reference code and page content among various callable elements of a web site.
Using the invention, ASPs are able to appear to other files as objects with associated methods and properties. The methods are written in a widely supported language (for example, Javascript, Livescript, or JScript). The properties are stored on the server side so as to allow multiple clients to access stored properties. Proxies of the properties are transmitted from the ASP to the client as needed.
Also, according to the invention, ASPs may contain various objects within each single page. Instead of creating each separate ASP to support a particular set of functions, the functions may be converted into objects and stored in a general ASP. Based on these adaptations, ASPs are readily adopted by high level programmers trained in object-oriented programming rather than to manually written executable scripts for HTML pages.
One technique of referring to ASPs as objects, and the nesting the objects within the ASPs, is through design-time controls developed by Microsoft(copyright). Additional disclosure of design-time controls is described in U.S. Ser. No. 08/959,300, entitled xe2x80x9cMethod and Apparatus for Automatic Generation of Text and Computer-Executable Codexe2x80x9d, filed on Oct. 28, 1997, the contents of which are incorporated for any and all essential subject matter. A design-time control may be a form of a generic control (for example, an ACTIVEX(copyright) control, of the Microsoft Corporation of Redmond, Wash.). In general, a design-time control allows a developer to place a script in a document that alters or enhances the operation of the document.
Design-time controls incorporate wizard-like interfaces that can be edited to modify the text they generate for a web page. DTCs take advantage of OLE design-time capabilities (including direct manipulations, property sheets, and persistence) to capture user inputs, thereby extending the capabilities of editors that support design-time controls.
A design-time control differs from a general control in that it operates only in an editor (or container) when a web site is being designed or maintained. Once the web site is saved, the design-time control may create (among other things) script for the client/server/ASPs. As applied to the present invention, the developer uses the design-time control to attach object identification information including method and property information to each ASP. When saved, the attached object identification information and methods and properties are converted from the high level, object-oriented programming language into the appropriate HTML recognizable representations so that any client/server system supporting HTML may use the rendered client/server files. Currently, end users are limited to a small number of browsers. By using design-time controls to write multiple versions of the client/server script, the number of different clients"" browsers and servers that can be supported almost limitless because each browser can be supported in one or more DTCs.
Editors insert design-time controls, which allow a page to operate as an object (referred to as a xe2x80x9cpage objectxe2x80x9d or xe2x80x9cP.O. DTCxe2x80x9d) into the ASP files. These xe2x80x98P.O. DTCsxe2x80x99, when instantiated in an editor, provide the user interface which supports the disclosed programming model reduced with naming requirements. When run in an editor, the P.O. DTC prompts the user for various information regarding the file itself (e.g., xe2x80x9cam I an object? What are my method and properties?xe2x80x9d). Thus, the page object is put onto the page by the user. The user interacts with the DTC""s user-interface to indicate what methods and properties define the page as an object. As a result, the DTC generates the appropriate script (client-side or server-side).
As used herein, a persist operation refers to writing information to a non-volatile storage medium where the information relates to the current state of an object. The information written is such that, when the object is recreated in memory, the object can be restored to its previous state. Herein, an instantiate operation refers to creating an instance of an object type in memory.
In one embodiment, the present invention uses a Component Object Model (COM) component thereby allowing the controls to be utilized across multiple applications. Advantageously, the present invention may be implemented within any type of HTML editor, including but not limited to, Front Page 98(copyright) and Visual InterDev 98(copyright) editors.
As used herein, ASP objects are generalized with the scripting namespace of page.method and page.property. The xe2x80x9cpagexe2x80x9d is the ASP page. The xe2x80x9cmethodxe2x80x9d and xe2x80x9cpropertyxe2x80x9d are those associated with the page, as specified through the P.O. DTC.
The present invention may be utilized in applications that require complex or lengthy scripting thereby alleviating the burden on developers or programmers. Also, the programmer need not know all of the details necessary for scripting since the control of the present invention can perform the necessary scripting. Such applications may include applications incorporating complex database controls, for example.
The script generated by the Page Object DTC includes server script, which creates a JavaScript object. The JavaScript object is given the name that user assigned to the Page Object. That object may then be referenced by script on the page whenever the public methods and properties of the Page Object are to be accessed. For example, if the user assigned the name xe2x80x98Statisticsxe2x80x99 to the Page Object and wanted to access the xe2x80x98Totalsxe2x80x9d property, the user would write script that referenced the name xe2x80x98Statistics.Totals.xe2x80x99 Note that the script needed to construct the xe2x80x9cStatisticsxe2x80x99 object was generated by the Page Object DTC at design time.
As noted above, the server script may be different from the client script. Here, on the JScript proxy object is created for the server side and one for the client side. These may be different since the methods and properties accessible in each domain may differ. For example, ASP page xe2x80x9cFooxe2x80x9d contains three methods: A, B, and C. The developer makes A accessible on the client and server, makes B accessible on the server, and C accessible on the client. The resulting server proxy object would provide A and B methods, while the client proxy object would provide A and C methods. Using the term xe2x80x9cexposedxe2x80x9d in this example, the developer exposed A and B to the server and exposed A and C to the client.
Methods exported by the Page Object according to the invention are implemented as server methods. As the enclosed document describes, there are other methods associated with the Page Object which are automatically available with the Page Object, but they are conventional methods which are available in the local xe2x80x98spacexe2x80x99 (the document describes the term xe2x80x98spacexe2x80x99).
To simplify the programmer""s task of navigating between pages, constructs such as window.location.href=page.asp?routing=shuffleandparameter1=value are replaced by constructs such as page.navigate.shuffle (value), which are more natural for a programmer.
Further, the editing environment may be modified to replace all scripting requirements with a xe2x80x9cdrag-and-dropxe2x80x9d interface where each new object is dropped into a page and, through the use of property and method pages, modified in accordance with the developers requirements.
In this case, the developer need never interact with the HTML; rather, the editor would convert the various objects into clientside/serverside/ASPs scripts and pages as appropriate. The present invention may be implemented by any number of editors. Available editors include, for example, Visual InterDev 98 and FrontPage 98 (by the Microsoft Corporation).
These and other novel advantages, details, embodiments, features and objects of the present invention will be apparent to those skilled in the art from following the detailed description of the invention, the attached claims and accompanying drawings, listed herein, which are useful in explaining the invention.